Node / meshtastic / Meshtastic-Android / files / .coderabbit / ast-grep-rules / presence-vs-sentinel-zero-signal.yml

Displaying Raw • Download

T8b949e# Class A of "Recurring Defect Classes" in .skills/code-review/SKILL.md, enforced mechanically.

T8b949e# Presence in this repo is nullability: the models are Wire-generated, so there is no hasX()

T8b949e# accessor — an optional field is simply a nullable type. The proto `rx_rssi` only becomes `Int?`

T8b949e# in protobufs 2.7.26.138 (PR #6498, still open at time of writing); on the pinned 2.7.26.130 it

T8b949e# is `Int = 0`. So this rule currently guards APP-level nullable rssi (parameters, state, BLE

T8b949e# advertisement values) and becomes a proto regression guard once #6498 lands.

T8b949e#

T8b949e# INT LITERALS ONLY, deliberately. RSSI is an integer dBm value everywhere in this repo —

T8b949e# proto `rx_rssi: Int`, `Node.rssi: Int`, `MetricFormatter.rssi(value: Int)` — and there is no

T8b949e# Float-typed rssi declaration anywhere. Adding `?: 0f` / `takeIf { it != 0f }` variants here

T8b949e# would be dead patterns. Float sentinels on genuinely-Float metrics are the float rule's job.

T8b949e# RSSI only, deliberately NOT snr: rx_snr still has no proto presence upstream, so a 0f guard there

T8b949e# is genuinely ambiguous and unfixable app-side — flagging it would be pure noise on code nobody can

T8b949e# correct. Also excludes `replyId ?: 0` and `packet.from.takeIf { it != 0 }`, which are legitimate

T8b949e# because 0 there means "unset", not "a measurement of zero".

Tff7b72idTb4b4b4: Ta5d6ffpresence-vs-sentinel-zero-signal

Tff7b72languageTb4b4b4: Ta5d6ffkotlin

Tff7b72severityTb4b4b4: Ta5d6ffwarning

Tff7b72messageTb4b4b4: Tb4b4b4>Tb4b4b4-

Tff7b72Zero-default on a signal metric conflates "not reported" with a real reading. 0 dBm is a

Tff7b72valid RSSI (SX126x reports exactly 0, SX127x can go positive) and on a signal-strength scale

Tff7b72it renders as the STRONGEST value — so an unknown signal displays as excellent. Keep the type

Tff7b72nullable and branch on null, rendering absence explicitly rather than substituting a number.

Tff7b72noteTb4b4b4: Tb4b4b4>Tb4b4b4-

Tff7b72See .skills/code-review/SKILL.md, "Recurring Defect Classes", class A. rx_snr still has no

Tff7b72proto presence upstream, so its 0f ambiguity cannot be fixed app-side — do not re-raise that.

Tff7b72ruleTb4b4b4:

Tff7b72anyTb4b4b4:

Tb4b4b4- Tff7b72patternTb4b4b4: Ta5d6ff"Ta5d6ff$RECV.takeIfTe6edf3 Ta5d6ff{Te6edf3 Ta5d6ffitTe6edf3 Ta5d6ff!=Te6edf3 Ta5d6ff0Te6edf3 Ta5d6ff}Ta5d6ff"

Tb4b4b4- Tff7b72patternTb4b4b4: Ta5d6ff"Ta5d6ff$RECVTe6edf3 Ta5d6ff?:Te6edf3 Ta5d6ff0Ta5d6ff"

Tff7b72constraintsTb4b4b4:

Tff7b72RECVTb4b4b4:

Tff7b72regexTb4b4b4: Ta5d6ff"Ta5d6ff(?i)rssi$Ta5d6ff"